Graphical modeling has spawned a variety of software products such as Simulink® from The MathWorks, Inc. of Natick, Mass., that cater to various aspects of dynamic system analysis and design. Such products allow users to perform various types of tasks including constructing system models through a user-interface that allows drafting block diagram models, allowing augmentation of a pre-defined set of elements with custom user-specified elements, the use of the block diagram model to compute and trace the temporal evolution of the dynamic system's outputs (“executing” the block diagram), and automatically producing either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of it (referred to herein as “code generation”). Each of the tasks listed above has many intricate details and subtle variations.
Graphical modeling environments allow developers to create an element for a graphical model using a computer language to describe the element. A developer may have direct access to the source code of the graphical modeling environment and may be able to create user-specified elements to implement a functionality desired by the developer or in some cases an application program interface (API) may be provided. For example, Simulink® provides an API that allows S-functions to be written in C, C++, Ada, Fortran, or MATLAB® from The MathWorks, Inc. of Natick, Mass. S-functions use a special calling syntax that enables a user to interact with Simulink®. The form of an S-function is very general and can accommodate continuous, discrete, and hybrid systems. As such, S-functions allow a user to add their own elements to a block diagram model.
Conventionally, graphical modeling environments burden developers of elements by requiring a developer to write a first set of code to support simulation of an element and a second, separate set of code to support code generation for the element. While the two independent implementations are robust, they impose a large amount of work upon developers for implementing both simulation and code generation and maintaining their consistency. In addition, simulation is typically performed based on an in-memory representation of the model that is structured based on the elements that are present in the model. This is inconvenient for simulation since optimizations across elements of a graphical model cannot be achieved. Further, the in-memory representation of the model behavior may be unduly burdened with the graphical structure of connected elements. Graphical modeling environments also burden developers of elements by requiring a developer to write methods to support propagation of compiled information of elements.
Given the above, there is a need for the ability to have a single code for an element that supports simulation and code generation. The single code may also support propagation of data and model characteristics. That is, it is a desire to enable creation of one element that can directly support simulation, propagation and code generation.